Skip to main content

Access Policy Configuration Guide

This guide explains how to configure and use Access Policy effectively for end users and tenant administrators.

What Access Policy Does​

Access Policy is an additional access gate for a Type. It does not replace existing access grants.

Access to an instance is allowed only when both checks succeed:

  1. Baseline access check passes.
  2. Access Policy rule (if configured) evaluates to true.

If baseline access fails, Access Policy is not evaluated.

Access Evaluation Flow​

The system evaluates access in this order:

  1. Primary Access Check
  • Default everyone access
  • Explicit user or role access
  • Admin bypass
  1. Access Policy Rule Evaluation
  • Evaluates configured rule expression for the selected Access Policy rule
  • Uses instance attributes and user profile attributes in condition logic
  1. Final Decision
  • Allow only if both primary access and policy checks pass
  • Deny if policy check fails

Configuration Model​

Access Policy is configured by selecting a single rule in the Type Access section.

A rule typically contains:

  • Rule Groups combined with AND/OR operators
  • Conditions within each group
  • Optional Error Message expression returned on denial

Setup Steps in Admin App​

How to create Rule​

  1. Login to Admin App.
  2. Go to Schema > Rules.
  3. Click Create Rule.
  4. Enter Rule Name.
  5. Add Error Message expression (recommended).
  6. Configure Attribute Filter Groups.
  7. Configure Attribute Filter Conditions in each group.
  8. Click Save.

Add rule into Type​

  1. Go to Admin App > Schema > Type.
  2. Open the target Type.
  3. Open the Access tab.
  4. In Access Policy dropdown, select the Rule.
  5. Click Save.

Quick Validation After Save​

  1. Test with one user who should have access.
  2. Test with one user who should be denied.
  3. Verify the denial message is clear and actionable.

Where to Use Access Policy​

Use Access Policy when you want context-aware control over who can interact with a specific instance.

1. Control who can view an instance​

Use case:

  • A user can view an instance only when instance data matches the user profile.

Examples:

  • Instance Region equals User Region
  • Instance Department equals User Department
  • Instance Creator equals Context User

2. Control who can edit or update an instance​

Use case:

  • Users can update only the instances that belong to their scope (for example same branch, business unit, or account ownership).

Recommended approach:

  • Use Access Policy to allow access only to in-scope instances.
  • Combine with role or state/action permissions so only authorized users can perform edit/update actions.

3. Control who can delete an instance​

Use case:

  • Deletion should be limited to instance owners or privileged users in a matching organizational scope.

Recommended approach:

  • Use Access Policy to narrow eligible instances.
  • Combine with delete permission controls (role/state/action level) to enforce who can actually delete.

4. Enforce owner-only or manager-only operations​

Use case:

  • Owners can modify their own records, while managers can modify records only in their managed unit.

Examples:

  • Owner rule: Instance Creator equals Context User
  • Manager scope rule: Instance BusinessUnit equals User ManagedBusinessUnit

5. Protect sensitive instances​

Use case:

  • Sensitive records should be visible and editable only when user clearance/role attributes match instance sensitivity attributes.

Examples:

  • Instance SensitivityLevel in User AllowedSensitivityLevels
  • Instance Country equals User AllowedCountry

Rule Group Logic​

Use logical operators carefully:

  • AND within a group: all conditions in that group must evaluate to true.
  • OR within a group: at least one condition in that group must evaluate to true.
  • AND between groups: every group must evaluate to true.
  • OR between groups: at least one group must evaluate to true.

Condition Elements​

Each condition includes:

  • Attribute Context: Instance, User, or User Roles
  • Attribute Name: The field to evaluate (Hidden for User Roles context)
  • Condition Operator: For example Equals, In, Is Empty, Between
  • First Value / Second Value: Static or dynamic input values (depending on condition). For User Roles, this is a selection of available system roles.

Dynamic Value Support and Limitations​

Supported​

  • Dynamic value resolution supports User Profile attributes.
  • Static values are supported for all relevant conditions.

Not Supported​

  • Dynamic values that reference Instance attributes are not supported for first/second value resolution.
  • Invalid type attribute names and invalid user profile attribute names do not throw a hard UI error at runtime evaluation; the condition evaluates to false.

Practical Outcome​

Any invalid reference or unsupported dynamic format in a condition can silently make the condition false. This can deny access unexpectedly when groups are combined with AND.

Error Message Behavior on Denial​

When access is denied by Access Policy:

  • If a rule error-message expression is configured: expression is evaluated and returned in the access denied response.
  • If not configured: the platform default access denied message is returned.

Use concise and user-friendly denial messages so users can understand what to check next.

Example Patterns​

1. Instance Creator Only​

Goal: Users can access only instances they created.

Instance Creator Access Policy

Image details:

  • Attribute Context: Instance
  • Attribute Name: Creator
  • Condition: context user
  • Purpose: only the user who created the record can access it.

Pattern:

  • Context: Instance
  • Attribute: Creator
  • Condition: Context User

2. Regional Isolation​

Goal: Users access instances only from their own region/country.

Regional Isolation Access Policy

Image details:

  • Attribute Context: Instance
  • Attribute Name: Country
  • Condition: equals
  • Dynamic Value Enabled: true
  • First Value: @User.Country
  • Purpose: users can access records only from their own country/region.

Pattern:

  • Context: Instance
  • Attribute: Region/Country
  • Condition: Equals
  • First Value: Dynamic user profile attribute such as user country

3. Device-Type Scoped Access​

Goal: Users access member-device records only for authorized device types.

Device Type Scoped Access Policy

Image details:

  • Attribute Context: Instance
  • Attribute Name: MemberDeviceType
  • Condition: in
  • Dynamic Value Enabled: true
  • First Value: @User.DeviceType
  • Purpose: users can access only devices matching their authorized device types.

Pattern:

  • Context: Instance
  • Attribute: Device Type
  • Condition: In / Equals
  • Value source: User profile authorization values

Known Limitations​

  • Access Policy is evaluated only after baseline access; it cannot grant access by itself.
  • Unsupported dynamic value references can lead to false conditions.
  • Incorrect attribute naming in condition configuration can produce consistent denial due to false evaluation.
  • Highly complex nested logic is harder to validate and maintain; use smaller logical groups.

Troubleshooting Checklist​

If users are unexpectedly denied access:

  1. Verify baseline access first (default everyone, role, or direct user access).
  2. Confirm the correct Access Policy rule is selected for the Type.
  3. Validate all attribute names used in conditions.
  4. Verify dynamic value references point to valid user profile attributes.
  5. Test each group independently before combining with AND.
  6. Review whether condition operators match attribute data types.
  7. Add or refine rule error-message expression to improve diagnosability.
  8. If images are not visible in docs preview, verify files exist under AccessPolicy/assets and restart the docs dev server.
  1. Start with a simple rule and test with real user personas.
  2. Add one condition group at a time.
  3. Use explicit naming for rules and groups to simplify support.
  4. Pilot in non-production with representative data.
  5. Monitor access-denied feedback and adjust rule clarity/messages.

Best Practices​

  • Keep logic readable and business-focused.
  • Prefer explicit user profile attributes for dynamic comparisons.
  • Avoid overloading one rule with too many unrelated conditions.
  • Document policy intent for each Type so admins can maintain it safely.
  • Re-validate policy after schema changes to attributes or user profile fields.